The invention relates to the aggregation of sensors and/or actuators, in particular to the aggregation of sensors and/or actuators by the use of a device register and a wiring broker.
The connection of various devices or sensor elements involves the following steps: 1. definition of the kind of data to be exchanged, 2. specification and agreement on a suitable protocol, 3. implementation of the protocol on both sides, and 4. communication can then be established.
The communication that is now established is strictly bound to the limits as defined in step 1. In this case it is known at design time which elements are to be connected to which others and what specific intended mode of operation or contribution is expected. Such connections can then rely on well defined low level specified protocols. The system designers can explicitly plan the expected exchange of information both semantically and syntactically on a low level. In many cases such designs are even done on a peer-to-peer basis. Controllers address explicitly their target elements in a bilaterally defined way. In order to achieve at least some abstraction and establish some re-usability sometimes several different, almost always incompatible, protocols are defined to generalize addressability and inter connectivity.
In the domain of house automation examples are: EnOCean, KNX, Modbus, M-Bus. Sometimes yet another higher level protocol then tries to map those lower level protocol into a common denominator. In the aforementioned example this would be Obix (Object building exchange). Obix tries to abstract the four lower level protocols into a well defined common XML syntax.
Using Obix then it would be possible e.g. to turn the light on in a building without knowing the details of either of the lower level protocols and independent from which one of these protocols is actually used in the specific building instance at hand. However, in order to make this happen the Obix protocol needs a semantically and syntactically well defined, rigid, low level mapping of all the control elements. In this example it must explicitly know about the action of ‘turning on the light’ and how this is to be mapped to the lower level protocols. Each and every possible action and its meaning must be specified in detail for the system to work properly. Explicit semantics is required for the connectivity of the different sensors/actuators/devices.
One of the most severe drawbacks of this approach is its lack of scalability. With each new device and each new possible connection and sensor or actuator control, the system needs explicit definitions for the interaction pattern to all other already existing elements that the new element might be connected to. This lead sooner or later into an unmanageable N×M relationship problem.